home *** CD-ROM | disk | FTP | other *** search
Text File | 1990-04-16 | 1.3 KB | 59 lines | [TEXT/GEOL] |
- Item forwarded by A33 to A34
-
- Item 6816533 13-April-90 15:51PDT
-
- From: ANIMATRIXDEV Animatrix, Steven Marcus,PRT
-
- To: MACAPP.TECH$ MacApp Technical
-
- cc: MACAPP.TEST MacApp SQA Team
-
- Sub: 2.0 InModalMenuState bug
-
-
-
-
- Hi!
-
-
-
- Another bug in MacApp 2.0 (3/22/90).
-
- I opened a deskaccessory and was unable to pull-down any menus!!
-
- As it happens the logic in the following routine is a little faulty, ie the
- case of a non-macapp window that isn't modal windowKind isn't handled:
-
- FUNCTION TApplication.InModalMenuState: BOOLEAN;
-
- VAR
- aWindow:TWindow;
- aWindowPtr: WindowPtr;
-
- BEGIN
- InModalMenuState := false; <---- this line is missing
-
- aWindowPtr := FrontWindow;
-
- { in case the front window is an alert or something }
-
- IF (WMgrToWindow(aWindowPtr) = NIL) & (aWindowPtr <> NIL) THEN
- CASE WindowPeek(aWindowPtr)^.windowKind OF
- dBoxProc, plainDBox, altDBoxProc:
- InModalMenuState := TRUE;
- END
- ELSE
- BEGIN
- aWindow := GetActiveWindow;
- InModalMenuState := (aWindow <> NIL) & NOT aWindow.AllowsMenuAccess;
- END;
- END;
-
-
- The bug doesn't strike very often because MPW allocates space for the function
- result with a CLR.W -(A7), BUT Think Pascal 3.01 doesn't!!
-
- thanks
- Steven Marcus@AnimatrixDev
-
-